﻿namespace IndustrialProgrammingProject.Rules
{
    /// <summary>
    /// Содержимое этого класса описывает правила, которые не отображаемы на примерах.
    /// Реализовать в примерах или вынести в отдельный документ.
    /// </summary>
    public class ExtraRules : IRightRule
    {
        // Стандарт кодирования.
        //
        // Cпециалисть уровня "менеджер - бывший программист", должен быть в состоянии 
        // прочесть и понять любой код в проекте.
        //
        // Все неявное, хитрое, заумное запрещено
        // (исключение инкапсуляция трудностей внешнего мира и технических реализаций внутри метода, иногда класса).
        //
        // Закон - Коллективное владение кодом.
        // Код, общее имущество. Нет кода, который принадлежит одному или сокращенной группе разработчиков.
        //
        // Удалять не используемый код!.
        // Все, классы, перечисления, интерфейсы, переменные, свойства, комментарии и т.д!
        // Все что не используется должно быть незамедлительно уделано!
        // Боритесь за уменьшение области сопровождения!
        //
        // Модификаторы доступа - private, public, inteernal и другие все.
        // Нельзя не указывать модификаторы доступа.
        // На каждой сущности должен быть явно проставлен ее модификатор доступа.
        // Самый желаемый модификатор доступа в проекте - private!
        // Самые плохие и нежелательные - все открывающие доступ, например - public, protected, internal.
        // Всегда стремитись заменить их на private.
        // Наказание: За задание доступа выше чем требуется назначается суровое наказание.
        // Например вы создали protected или public свойство, которое потребляется только в классе его содержащем.
        // Такое свойство должно быть private. Объяснения "Оно раньше использовалось или оно будет использоваться" не принимаются.
        // Это ваша работа при рефакторинге и создании максимально занижать доступ.
        // 
        // Очень большие методы.
        // Запрещены категорически.
        // Метод служит одной цели.
        // Иногда двум, что обязательно отражено в названии.
        // Разбивайте большой метод на мелкие методы служащие одной цели с явным названием.
        // Разбивайте большой метод на мелкие методы служащие одной цели с явным названием.
        //
        // Очень большие классы.
        // Это плохо и должно вызывать подозрения.
        // Если сразу не удается разбить большой класс на несколько мелких, то нужно разнести его на несколько файлов
        //  при помощи модификатора partial с добавлением в название префикса с точкой, поясняющей назначение.
        // MyClass.cs и MyClass.SomeLogic.cs
        // Но нужно помнить, что это лишь начальный шаг рефакторинга.
        // Разнесение класса на несколько файлов тоже подсказывает, что класс нуждается в
        //  рефакторинге и должен быть разбит на несколько мелких классов.
        //
        // Пробелы или табуляция - что использовать.
        // В C# принято использовать табуляцию, но адепты технологии выражают следующее мнение.
        // Т.к. по умолчанию в Visual Studio стоит настройка на пробелы в качестве отступа,
        //  то это решающий фактор для отказа от табуляций в пользу пробелов.
        // Особенно в случае внешних сотрудников и пришедших из других технлогий разработчиков.
        // Итог - важно не что именно, пробелы или табуляция используются в качестве отступов, а чтоб у всей команды был единый подход.
        //
        // Legacy Code.
        // Отделяйте пахнущий код от хорошего. Стройте границы между хорошим, проверенным, грамотный кодом и пахнущим кодом.
        // Не доверяйте ужасному коду.
        //
        // Паттерн безнаказанного Маньяк-Убийца.
        // Когда пишете код, всегда думайте, что вы его пишете для неуравновешенного маньяка убийцы, которому все сойдет с рук.
        // Если у него будет проблемы с вашим кодом, то вам скоро все станет берзразлично на этом белом свете.


        // Равенство.
        // Мы равны, мы реально равны и это особенность возможностей нашего головного мозга и нашей профессии,
        // поэтмоу не стесняйтесь сказать самому почетному кодеру в команде, что он пишет нечитаемый код.
        // Помните, плохое кодирование имеет огромные финансовые последствия для проекта, которые вы не в состоянии оценить.


        // Не спишите зачислить имеющееся правило кодирования команды в плохие правила.
        // Главное не правильность того или иного правила, а главное его наличие.
        // Единобразный стиль кодирования всей команды важнее!





        // TODO.it3xl.ru: Описать.
        
        // Борьба со сложностью.

        // Борьба с зависимостями.

        // Борьба с ошибками.

        // Правило - код, общее имущество. Коллективное владение кодом.

        // Котроль входных изменений, контроль внешних фич.

        // Контроль технологий.

    }
}
